Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some more cleanups in Assembly/Binder/Loader area #59590

Merged
merged 23 commits into from
Oct 11, 2021
Merged

Conversation

VSadov
Copy link
Member

@VSadov VSadov commented Sep 24, 2021

More tidy-up and removal of no longer necessary code.

  • moved default binder allocation to AppDomain::Create
    As discussed in the previous PR.
  • folded PEFile into PEAssembly. We only have PEAssembly now.
    All the PE files we deal with are assemblies and PEFile is unnecessary abstraction that was created to support modules, resource-only files, IStream things provided by SQL host, etc... None of that exists any more.
  • Renames and cleanups related to the PEAssembly change.
    Unlike PEFile, PEAssembly is always an assembly, never a native Resource PE, always has metadata, has MDImport right after construction, its PEImage is opened at construction and also has metadata, and so on...
    Many checks and conditions could be simplified.
  • AppDomain no longer has a scenario when a hosted assembly is updated after publishing, so the code supporting such scenario can be removed.
  • Some cleanup of PEImage - moved instance filed declarations together, sorted related public/private members, removed unused/redundant stuff.
    I.E. GetLayout is always called with LAYOUT_CREATEIFNEEDED, so the flag is unnecessary, and similar changes. Overall functionality is the same as before.

@ghost
Copy link

ghost commented Sep 24, 2021

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

In-progress. Running tests.

One of the goals is to combine PEFile and PEAssembly.
All the PE files we deal with are assemblies and PEFile is unnecessary abstraction that was created to support modules, resource-only files, IStream things provided by SQL host, etc... None of that exists any more.

Later we should look at how much sharing is between PEAssembly, PEImage and BINDER_SPACE::Assembly.

Author: VSadov
Assignees: -
Labels:

area-AssemblyLoader-coreclr

Milestone: -

@VSadov VSadov marked this pull request as ready for review October 4, 2021 16:44
Copy link
Member

@elinor-fung elinor-fung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked through the headers so far.
I'm a pretty slow reviewer over here 😬

src/coreclr/vm/ceeload.cpp Outdated Show resolved Hide resolved
src/coreclr/vm/commodule.cpp Outdated Show resolved Hide resolved
src/coreclr/vm/peassembly.h Show resolved Hide resolved
src/coreclr/vm/peassembly.h Outdated Show resolved Hide resolved
src/coreclr/vm/peassembly.h Show resolved Hide resolved
src/coreclr/vm/peimage.h Outdated Show resolved Hide resolved
src/coreclr/vm/peimage.h Outdated Show resolved Hide resolved
Comment on lines 1263 to 1265
// TODO: we used to return "m_pMDImport_UseAccessor" here, - a field that was never initialized to anything.
// we should verify whether this codepath is actually reachable.
// return (TADDR)m_pMDImport_UseAccessor;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dotnet/dotnet-diag?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is weird, but should be left as it was.

We rename PEFile::m_pMDImport to m_pMDImport_UseAccessor when compiling for the DAC, because we want it to be a compile error if anybody tries to use m_pMDImport in the DAC, since m_pMDImport is the TADDR (debuggee side address) and not a PTR_* that knows how to magically read the value from the debuggee.

However, this one method we actually want to read the TADDR value , do we use m_pMDImport_UseAccessor directly in the DAC code. The code in DacDbiInterfaceImpl::GetPEFileMDInternalRW calls GetMDInternalRWAddress, which will read the right value since m_pMDImport_UseAccessor has the same type and offset as m_pMDImport

Copy link
Member Author

@VSadov VSadov Oct 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @davmason!! I think I got it. I also think this deserves a better comment. It is fairly hard to figure where and how this field is used by just searching around.
I will try adding your comment there as well in some form - at least it would hint that there is more going on than a textual search might reveal.

src/coreclr/vm/peassembly.h Outdated Show resolved Hide resolved
src/coreclr/vm/peassembly.h Show resolved Hide resolved
VSadov and others added 2 commits October 5, 2021 09:17
Co-authored-by: Elinor Fung <elfung@microsoft.com>
@VSadov
Copy link
Member Author

VSadov commented Oct 5, 2021

@elinor-fung @davmason - I think I have addressed all the comments. Please take a look that all makes sense and I did not miss something.

// be the parent assembly for dynamic or memory assemblies
const SString& GetEffectivePath();

// Codebase is the fusion codebase or path for the assembly. It is in URL format.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another reference to "fusion" which should be removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick search finds 48 references to "fusion" in the comments. It is not always clear how to re-word them, and the old context may still be useful while refactoring.
I think it may be worth to revisit "fusion" comments a bit later. Fortunately it is such an easy thing to find.

Copy link
Member

@davmason davmason left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The diagnostics side stuff looks good to me, I didn't take a look at the broader code changes though

src/coreclr/vm/encee.cpp Outdated Show resolved Hide resolved
@@ -4299,7 +4286,7 @@ HRESULT ProfToEEInterfaceImpl::GetILFunctionBody(ModuleID moduleId,
// Yay!
MODE_ANY;

// PEFile::CheckLoaded & Module::GetDynamicIL both take a lock
// PEAssembly::HasLoadedPEImage & Module::GetDynamicIL both take a lock
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still true for PEAssembly::HasLoadedPEImage?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not true for PEAssembly::HasLoadedPEImage, but still true for Module::GetDynamicIL

src/coreclr/vm/assembly.cpp Outdated Show resolved Hide resolved
src/coreclr/vm/peimage.cpp Outdated Show resolved Hide resolved
src/coreclr/vm/peimage.cpp Outdated Show resolved Hide resolved
src/coreclr/debug/daccess/daccess.cpp Outdated Show resolved Hide resolved
src/coreclr/vm/peassembly.cpp Show resolved Hide resolved
src/coreclr/vm/peassembly.cpp Outdated Show resolved Hide resolved
src/coreclr/vm/peassembly.cpp Outdated Show resolved Hide resolved
{
WRAPPER_NO_CONTRACT;
SUPPORTS_DAC;

// sizeof(PEFile) == 0xb8
// sizeof(PEAssembly) == 0xb8
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment about the size still true?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most likely not and I do not know what it means. I do not think we have dependency on the size of the instance and I am not sure the size was correct before - was it for x86 or x64, etc?
There is no PEFile anyways. I will remove the comment.

VSadov and others added 2 commits October 7, 2021 13:39
Co-authored-by: Elinor Fung <elfung@microsoft.com>
@VSadov
Copy link
Member Author

VSadov commented Oct 11, 2021

@elinor-fung - anything else that could be addressed on this PR?

Copy link
Member

@elinor-fung elinor-fung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry - completely missed coming back to this. Looks good to me.

@VSadov
Copy link
Member Author

VSadov commented Oct 11, 2021

Thanks!! They were good suggestions.

@VSadov VSadov merged commit 7088332 into dotnet:main Oct 11, 2021
@VSadov VSadov deleted the aloader05 branch October 11, 2021 20:52
@ghost ghost locked as resolved and limited conversation to collaborators Nov 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants